1. Field of the Invention
In general, the present invention relates to the field of displaying web pages via the Internet and, more particularly, to a system that can easily store data related to the web pages in extensible markup language (XML).
2. Background
Increasingly, buyers and sellers involved in commerce are turning to the Internet to conduct their business electronically in a relatively fast and quick manner. The Internet is particularly attractive to buyers because it provides a vast knowledge base from which they can research and find information about respective purchases of various goods. Time can be saved because a consumer does not have to travel to various places, such as libraries or stores, to obtain information regarding the various goods to be purchased. Indeed, the entire process of shopping for goods and services can be completed using a personal computer at one's home so long as the computer is connected to a network such as the Internet.
Likewise, using the Internet for commerce is extremely attractive to businesses as they can provide the same type of information to consumers that was traditionally provided through catalogs or other advertising, but at much lower cost. Furthermore, transactions can occur between customers and sellers in a similar manner as customarily done at a checkout stand in a store. Indeed, in the case of all digital products, such as computer software, videos, music or funds transfer, the goods or services themselves can be delivered through the Internet and payment can be received through the Internet so that the entire transaction occurs through a computer network without the consumer or merchant ever actually meeting in a store. This method of doing business provides tremendous cost savings to manufacturers and sellers. Even items that have to be physically shipped can benefit from this form of commerce. Once a customer browses a merchant's website and selects various goods to purchase, the merchant simply needs to verify the use of the payment instrument and then ship the goods to the customer.
Typically, a merchant provides what is known as a web-store or an Electronic commerce store on the web. That is, the merchant either has a web server or uses a web server to create the store and the customer has client software to view the store. The client software can be any piece of code or software that resides on a computer, telephone, or any other type of computing/communication device that can talk to another computer such as a server. Typically, the client software is simply a standard piece of software such as a web browser. Typical web browsers on the Internet would include, for example, NETSCAPE NAVIGATOR or INTERNET EXPLORER. Such browsers provide a graphical user interface for retrieving and reviewing web pages found on web servers.
In order for the client web browser to function properly, the web server must send information in a format that the web client can display in a useful manner. Mainly, browsers will use hypertext transfer protocol (HTTP) via transmission protocol/Internet protocol (TCP/IP) to pass information back and forth between the web browser and web server. The actual document read by the web browser will most likely be in Hypertext Mark up Language (HTML). In addition, web browsers can read and display any type of text document.
Originally, web servers were designed just to present data. The data was transferred via the Internet by the above mentioned protocols in the HTML format and web browsers would simply present the data to an end user in a graphical manner. A browser would simply go to the web server and request a certain file and the web server would present the data in the HTML format such that the file would be transmitted to the web browser and a user could see something displayed on the screen in a graphical format. For example, a scientific paper about particle acceleration in a lab might be processed in this manner.
As technology has advanced on the Internet, web servers have become more complex and have gone beyond simply presenting a text document. For example, databases are now common on web servers. For example, if one wished to look up a telephone number, instead of having the web server send the entire phone book through the Internet as a large text document to a web browser, it is desirable to simply send the phone number. Essentially, software on the server has been developed that responds to a request for a phone number by determining what the phone number is from the large text file of a whole phone book, converting the answer into an HTML document and sending the answer to a web server as though it was a full text file. Therefore, a user would simply be able to see the single phone number, as opposed to all the phone numbers within the database. Essentially a text file is specially created for that one moment to respond to that one request. The text file does not actually exist in a database, rather the client web browser simply receives a HTML document that was requested. In fact, the browser is simply getting a set of data created based on the browser's query.
Currently, Electronic commerce stores are based on this interaction of data being sent from the client to a server. The server then processes the data and sends the data back to the web browser in a certain format. In the process of sending data back and forth, ultimately a purchase transaction occurs. Of course, this transaction is much more complex than simply retrieving a phone number. There may be a full list of different types of products available such as T-shirts or other clothing. Additionally, the clothing could have certain attributes such as different colors and prices.
The problem with this exchange of data is that the server has to remember all the previous data. For example, if a customer were to ask for a T-shirt and then request that the shirt be a blue T-shirt, the server would have to remember the customer was asking about T-shirts initially and that now the request is for a blue T-shirt rather than, for example, a blue set of long johns. All the information about the transaction, such as color, size and price, must be remembered in each session. In order to make this process work, typically the data used for each session is stored in what is referred to as a “shopping cart”, essentially modeling the process on the idea of going through a grocery store with a shopping cart and putting various products having various attributes within the cart which may be purchased at a later time.
Additional information might also be important, such as the location of the purchaser. If, for example, the purchaser lives in another country, such as Turkey, a cash payment simply will not work. Perhaps the only payment that might work is through a credit card, such as a VISA card, which may necessitate some currency exchange transactions based on the purchase. A lot of different data has to be collected and stored during this type of session.
Also, most store owners on the Internet would like their shop to look unique. In addition to the overall look of the store, store owners would like to tailor what information is collected from the customer and how various input fields are arranged on the customer's computer screen. A typical Electronic commerce store may address this problem by collecting a bunch of data in a pre-set step by step conversation in each customer session. On a first page, the web server asks exactly what is being bought out of a list. The second page in the session asks how the user is going to pay for the items selected. The third page will indicate whether or not the transaction will go forward, followed by authorization of the financial instrument. The system is fairly simple because there are only three pages, three interactions and the interactions always process the same information in the same order. If the transaction had not proceeded in this order, and if a customer changed his or her mind, the entire transaction would have to re-start from the beginning. The advantage is that the server knows exactly what information is going to come back at exactly what time so it can be stored easily by the server. Essentially, the customer fills out a form such that the data is sent in exactly the correct format because all the data elements are strictly defined. This sort of system works fairly well so long as all the variables to be used in the session are known ahead of time. However, the order and number of the steps cannot be changed.
Therefore, if a store is going to sell encryption software, for example, it needs to know in what country the customer resides before the store can show an order page because encryption software cannot be sent to certain countries. This is a different business process in that the order of presentation of the data has been changed. Such a change requires essentially an entire rewrite of the software residing on the web server and is extremely expensive. In simple terms, a store A could be designed to process a certain order form and payment information, while a store B could be designed to process almost the same order form and payment information, yet the entire code would have to be rewritten to change store A into store B. Indeed for every single minor change to the process of asking for information, a relatively large amount of code must be rewritten.
More specifically, stores have been made with HTML, requiring a backend script or program unique to each store. Such scripts generally expect to see variables input in a particular manner and order. The variable names are generally incorporated into the script and therefore are not easily modified. Of course, when a storeowner wishes to collect custom or additional information from a customer, the backend script or code must be changed to accommodate the new data coming into the web page.
Currently each store has an HTML form that is sent to a client computer into which customers enter information. The customer fills out the form and then the form data is sent to the storeowner's server. For example a traditional HTML input form may use the following variables:
<input name=“name”><input name=“street”><input name=“city”><input name=“state”><input name=“zip”>
A web server then parses the form data and collects the various pre-specified variables from the parsed form data. The data is then inserted into an organized database by the web server. Next, the web server creates a HTML response page which is transmitted to the customer and appears as a web page on the client computer.
However, a small change in the web store quickly illustrates the problem with this traditional HTML form. Say the store owner wished to collect the customer's first and last name. The form code would have to be modified to handle the new variables. A similar problem occurs when a store wants to group information about a product that a customer is buying, such as product size or color.
Another approach to the problem has been the use of electronic commerce stores which are relatively configurable. Essentially, these electronic commerce stores are programs that reside on web servers that have a tremendous number of options all preprogrammed. However, if the programmer has not thought of all the possible ways a merchant would like to configure the store, an extensive rewrite is necessary. Furthermore, the costs of writing a program with a large number of preprogrammed options is expensive.
Based on the above, there exists a need in the art for a piece of software that resides in a web server that can be easily adapted to many different types of Electronic commerce web stores.